\subsection{Feedback}
\label{prestudy:errororrectingcodes:feedback}
In a network setup with a reverse channel it is possible for the sinks to reply to the source for each packet, this feedback method is known as acknowledgement. It is then up to the source to retransmit any packet that the sinks does not acknowledge. However this may put unnecessary load on the channel if the majority of all packets are received correctly. This leads to the use of negative  acknowledgements, where the sink replies with a negative acknowledge if it detects a packet loss. There are several possible pit-falls when implementing feedback in one-to-many distribution schemes. If broadcasting to a large group of sinks, a single node consistently requesting retransmissions could ruin the network session for the other sinks. Initially, feedback schemes for broadcast scenarios are not considered and left for others to explore. For an overview of research on systematic feedback refer to \citep{5700469}.

\subsection{Forward Error Correction}
\label{prestudy:errororrectingcodes:forwarderrorcorrection}
The very basics of \ac{FEC} is adding redundancy to the data and thus requiring additional bandwidth. \ac{FEC} is preferred in a network setup where a reverse channel is either not desired or possible. \ac{FEC} can be implemented in numerous ways, each variant having its own characteristics. Some of the more simple \ac{FEC} methods such as parity, used in RS-232 \cite{electronic1969interface}, and checksum, used in both TCP \cite{IEEETCP} and UDP \cite{ISIUDP}, can be implemented as the sum of the digits, however this only enables the receiver to identify a finite number of transmission errors but not correct them. Several types of \ac{FEC} codes exist, and are widely used in channel-coding for bit error detection and correction in transmitted messages. Commonly used \ac{FEC} codes are \ac{LDPC} codes and Reed-Solomon codes, used in DVB-C2 and DVB-C respectively \cite{DVBSHEET}.

An important property for any \ac{ECC} is optimality which is defined by \eqref{eq:codeoptimality}.  Optimal codes are generally costly in computational resources. However, near optimal codes can be constructed which are less costly and some of them can be made arbitrarily close to an optimal code. \citep{CODINGTHEORY,RAPTORCODES}

\begin{align} 
&\text{Required coded symbols }= (1+\epsilon)\cdot k\label{eq:codeoptimality}
\intertext{Where:}
k&\text{ is the number of source symbols}\notag\\
\epsilon&=0\text{ for optimal codes}\notag\\
\epsilon&\rightarrow 0\text{ for near optimal codes}\notag
\end{align}

A Reed-Solomon code is an example of an optimal code \cite{CMUNOTES}. It is shown in Section \ref{sec:eep} that \ac{RLNC} can come arbitrarily close to being an optimal code. An important class of \ac{ECC} is called rateless codes. Rateless codes have the property that the amount of overhead in the code is determined by the number of encoded symbols generated which is not limited. A rateless code transmitter can keep sending encoded symbols for as long as desired. Out of all the encoded symbols, the receiver should be able to decode when $\epsilon \cdot n$ more than $n$ symbols have been received as defined in Equation \eqref{eq:codeoptimality}. Raptor codes, Luby Transform codes, and \ac{RLNC} are all different types of rateless codes with the above-mentioned properties. This project will focus on \ac{RLNC}, and how this can be used to improve broadcast transmission of data. \cite{mackay2004, RAPTORCODES, NCMOBDEV_09}

% Janus not happy about this!
% Although these types of codes help transmission of data, in a broadcast setup every node has to receive all unique data packets correctly, causing each particular node to wait for all nodes having received all packets correctly. This waiting session can be reduced significantly by introduction of rateless codes.

% Janus not happy about this!
% Rateless codes do not have a fixed code rate like the typical \ac{FEC} codes used in channel coding, hence the name \textit{rateless} codes. Rateless codes are used to generate a sequence of encoded symbols, from which any subset of symbols the set of source symbols can be recovered, as long as the encoded subset is of the same size as (or larger than) the size of the set of source symbols. These rateless codes can be beneficial for broadcast setups, because the receiving nodes need to collect any subset of encoded symbols with the same size as the original set of source symbols. This is the ideal case, practically a small overhead of encoded symbols is usually needed to recover the source symbols. 
%In a broadcast network \ac{FEC} codes can be applied to ensure that each sink can verify the received packets, and in the case of transmission error recover the corrupted packets if possible.


%\fixme{FIRST: Describe code rate, why standard FEC codes are quite useless for broadcast data distribution. SECOND: Describe how rateless codes can be extremely useful in unreliable broadcast setups. THIRD: Note the different rateless codes. LASTLY: Introduce Linear NC and then RLNC }

%\tanke{Jo: In DVB-S2 \ac{FEC} is used in the form of Low-density parity-check (LDPC) \cite{DVBS2}. This enables the receiver to correct transmission errors.}
%Low-density parity-check (LDPC) code benyttes i DVB-S2 og er en ekstra mulighed i 802.11n
